[レポート]ソフトウェアテストを改善するためのいくつかのアイディア #jassttokyo

こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。

私は2024年3月14日~3月15日に開催されているJaSSTソフトウェアテストシンポジウム-JaSST'24 Tokyoに参加させていただきました。

今回は聴講したセッションのうち、ソフトウェアテストをカイゼンするためのいくつかのアイデアについて私なりの概要やおすすめだと思ったポイントについてまとめたいと思います。

ソフトウェアテストをカイゼンするためのいくつかのアイデア

講演者

• 山口 鉄平 氏（LayerX）

JaSST Tokyoに記載されている講演者の情報はこちらです。

アジャイル開発における品質を得意とするプログラマー、コンサルタント、コーチ、トレーナー。 日立製作所でのソフトウェア開発技術の研究開発、ヤフーやfreeeでのアジャイル開発・自動テストの組織普及および自動テストシステムやテスト環境の開発・運用を経て、現在LayerXにてサービスのテストやQAの立案・実行に加え、事業部全体のテスト戦略の立案、テスト基盤の設計・開発に従事している。また、個人事業主として、自動テストやアジャイル開発に関するコンサルティングを提供している。 Regional Scrum Gathering Tokyoやテスト自動化研究会などの実行委員やソフトウェア品質管理研究会 研究コース４「アジャイルと品質」にも関わっている。 『Fearless Change』（丸善出版、2014）共訳。 『ソフトウェアテストをカイゼンする50のアイデア』（翔泳社、2022）翻訳。

概要

以下はセッションの内容より引用したセッションの概要です。

Gojko Adzic氏らによって書かれた書籍「Fifty Quick Ideas To Improve Your Tests」（日本語訳：「ソフトウェアテストをカイゼンする50のアイデア」）には、ソフトウェアテストの基本を学び、そのテストに関する活動を改善したい方向けに、数多くの改善のヒントが書かれています。 本講演では、その書籍から、いくつかのアイデアを取り上げ、訳者による解釈と具体的な実現方法や事例を紹介し、ソフトウェアテストの改善のヒントをお伝えします。

発表資料

私なりの概要

講演中のメモをベースにしているため必ずしも正しくありませんが、私としては以下のようにセッションの内容を受け取っています。

まとめ

• 講演者は「ソフトウェアテストをカイゼンする50のアイデア」という書籍を翻訳されています
  • ちなみにこの本の原作者は基調講演での講演者である Gojko 氏です

• 今回の講演ではこの書籍をもとに50のアイデアのうち十数個を抜粋して訳者自身のご意見とともに紹介してくださいました
• 書籍の対象者は明確に記載されている
  • 短い反復開発でのテスター、開発者
  • ソフトウェアテストの基本を理解し、テストに関する活動の改善方法についてアイデアを探している人
  • つまり「テストのことを知る最初の一冊目」として読む本では無いと考えられる
• 講演者としてはこの書籍は自分ひとりで読むと言うよりも、誰かと感想を言い合い合うようなやり方がおすすめとのこと
  • はじめから読まないでいい
  • 章ごとに続いているものではなく、興味がある部分を読んでいくやり方で良いと思うとのこと
• 紹介するアイディア
  • 1 & 2
    • 「フィーチャーではなくケイパビリティ（能力）を探索しよう」
    • 「実現手段と同様にユーザーがメリットを享受できるかどうか確認しよう」
    • ケイパビリティとは？機能というよりも、機能を通じてお客様にとって何ができるの？というものだと筆者は考えているとのこと
    • （私の感想）
      • 私の中でふわっとしてしまっているのですが、「アウトカム」的な意味なのかと思いました
  • 機能をチェックするのも良いけど、「決まった手順で機能が意図通りかどうか」をベースに考えるとどうしても発想の広がりが狭くなったりしがち
  • 3
    • 「感情を利用しよう」
    • ハッピーパスから始めるのは理にかなっているけど、それ以外も考えると良いよというアイデア
    • イライラしている時に行うような操作をしてみるとか
    • 例: 「リソース足りなくなったらどうなるんだろう」「連打したらどうなるんだろう」などの観点で考える
  • 4
    • 「入力同値クラスだけでなく出力同値クラスも考慮しよう」
    • エラー出力のような補助的な出力はそれほど注目されない。そのため、エラーハンドリングなどの処理は主要なワークフローよりもバグが多く、リスクの高い状態になりがち
    • （私の感想）
      • 質問を逃してしまいよくわからないままになってしまいました
        • 同値分割などで利用される意味の同値クラスだろうということや、出力結果の同値クラスも考えようぜという意味かと受け取っています
        • 「パラメーター不足のエラーが起きる無効同値クラス」「権限不足のためアクセスできない無効同値クラス」というような観点でエラーハンドリング部分もテストするという意味かと思いました
  • 5
    • 「最初にアサーションを書こう」
    • 出力から最初にかくようにすると一つのテストで同時にさまざまな内容をチェックする可能性は極めて低くなる
    • 1回目で完成させるのを期待するのではなく、出力と入力を意識して書く
    • （私の感想）
      • こちらは実際に自動テストのコードを書く時に意識しているような気がしています
      • テスト駆動開発を意識して書くときにもまずは「想定する挙動や仕様」に対して失敗するテストを書くと思うのですが、この時に想定されるアサーションを書きはじめていると思います
      • 今回の講演では全く触れられていないのですが、なぜか和田卓人氏の自動テスト駆動開発に関する記事を思い出していました。未読の方はぜひ参考にされてください
        • 保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
  • 6
    • 「手動テストを自動化するのはやめよう」
    • あちこちで言われているが、具体的にじゃあどうすればよいのか？手動は全くやらないのか？ということに関する考えもこの書籍では書かれているとのこと
    • 手動テストの利点を無視して自動テストを書くのはやめよう
    • 3 ~ 4ステップのやり方が書いてあるが、筆者も実際はその通りにやってない
  • 7
    • 「非同期データはテストの後にクリーンアップするのではなく、テストの前にセットアップしよう」
    • ここから主に自動テストを意識しているアイデアになると思うとのこと
    • 非同期処理の完全完了を待って、それを待って・・・とするのは結構難しい
    • それなら最初にセットアップしたほうがいいんじゃない？という意味らしい
    • （私の感想）
      • 例えばJestなどのテストツールでも前処理・後処理というような処理を書けます
        • セットアップと破棄 · Jest
      • 若干ここで意図する「非同期データ」とは意味が異なるかもしれませんが、テストの前提となる「DBの状態」などの処理も前処理でクリーンアップしたほうが良いことがありそうだなと思いました
        • 他のテストケースに影響しないようにデータをクリーンアップしておく必要がある
          • 例: Postリクエストで作成したデータが残っていると次のテストで重複チェックに失敗するなど
        • このとき「テストが全部終わったらデータをクリーンアップする」という処理では、途中で予期せぬエラーでテストが中断した時にきれいにならないで残ってしまうことが多々ある
        • なので「テストが始まる前にデータを必要ならクリーンアップする」であれば何回実行しても、前の実行結果に引きづられないでテストができて良さそう
  • 8
    • 「時間経過を待つのではなく、イベントを待つ」
    • （私の感想）
      • これはPlaywrightなどのツールを利用されている方にはとてもわかりやすいアイデアだと思いました
      • 例えばPlaywrightでは「ページが遷移した」を適切に待つためにいくつかの待ち受けるためのメソッドが用意されています
        • 例: waitForURL など。
        • Navigations | Playwright
      • 「ページ遷移まで5秒待つ」は環境に依存しますし、無駄に長い時間を設定してテストが長くなることも避けたいですよね
  • 9
    • 「テストを作業項目に沿ってグループ化したり構成したりすることを避けよう」
      • ここで言う作業とは？
      • イメージとしては開発しているユーザーストーリーとか作業、開発しているものとか
      • 要するにユーザーへの価値が見えにくいテストの単項目みたいな感じっぽいとのこと
      • （私の感想）
        • 作業の意味が少しわからなかったのですが、↓のような感じなんだっけ？と考えていました
        • とても好きなprivateメソッドのテストって書かない方がいいんだっけ？ - Speaker Deckで言うところの、Publicメソッドに閉じ込めたprivateメソッドのようなものかな？と思いました
        • ここで確かめたいのは「何らかの機能として提供している価値」という観点であって細かい「詳細」ではないというような意味なのかと考えました
        • 全然違うかもしれないので、分かった日がくればここを更新するかもしれません
    • テストを作業に紐づけるのではなく、お客様が使う観点とか視点とかに基づいてテストを分類してみると良さそうとのこと
  • 10
    • 「自動化パターンの具体例を集めたギャラリーを作ろう」
    • 他の人の書いたテストシナリオを見やすいようにしておくだけでも違うと思うとのこと
    • 講演者としても実際あまりギャラリーまで作るのを見たことはないと仰っていたと思います
  • 11
    • 「テストコードは書くためではなく読むために最適化しよう」
    • 例えばGUIのテストツールで書いたものを読むのがつらい。
      • E2Eテストは特に繰り返し実行する時間もだが、メンテナンスを続ける時間がとても長いので、読めるように最適化されたテストはとても大事
    • ちょっと油断すると「動いたからいいや」とか雑でもいいか。みたいになりがち。
    • 講演者的には
    • 語彙が整っていること（使われている語句がドメインにおいて適切な言葉になっていたりとか）
    • 例えばクリックする。ではなく検索する、とか保存する・。みたいな言葉を使うような感じだったりとか
  • 12 訳者が追加したアイディア（原著にはない）
    • 「自動テストは頻繁に実行し、割れ窓はすぐ塞ごう」
    • E2Eのようにフレーキーなテストになってくると、結構オールグリーンにならないことも結構ある
    • どんどん重い腰になっていく
    • 早めに治さないとこわれていることや、動いていないことにも気付けない

感想

• スクラムやアジャイル開発の中でテスト活動について悩んでいる人に対して何かしらの発見があると思いました
• 講演者であり訳者自身がおっしゃっていましたが題材となった書籍自体が「テストを何から勉強したら良いのか？」というものではないため、基本的なテスト活動の経験や知識がある方が「何かしらプロのアイデアが知りたいな」という時に良いのかと思いました
• 出版されている書籍に対して訳者自らが「おすすめの使い方」「興味のある部分を読むだけでも十分に元が取れると思う」と説明してくださることで、ハードルが非常に下がりました
• 「7つ目以降は結構自動テストを意識していますね」というふうに訳者自ら書籍の若干ふわっとした内容を補完してくれてたり、「原著のここが翻訳する時に困った」というTIPSを話してくれるのがとてもおもしろいです
• 私も書籍は持っているのでもう一度興味のある分野を読み直そうと思います